IBIS Macromodel Task Group

Meeting date: 31 oct 2006

Members (asterisk for those attending):
* Arpad Muranyi, Intel Corp.
* Barry Katz, SiSoft
* Bob Ross, Teraspeed Consulting Group
* Doug White, Cisco Systems
  Hemant Shah, Cadence Design Systems
* Ian Dodd, Mentor Graphics
* Joe Abler, IBM
* John Angulo
  John Shields, Mentor Graphics
  Ken Willis, Cadence Design Systems
* Kumar, Cadence Design Systems
* Lance Wang, Cadence Design Systems
* Michael Mirmak, Intel Corp.
  Mike LaBonte, Cisco Systems
  Paul Fernando, NCSU
  Randy Wolff, Micron Technology
* Richard Ward, Texas Instruments
  Sanjeev Gupta, Agilent
  Shangli Wu, Cadence
* Todd Westerhoff, Cisco Systems
* Walter Katz, SiSoft
  Vuk Borich, Agilent
  Vikas Gupta, Xilinx

-------------
Review of ARs:

- IEEE 1076c:  Michael suggested everyone log into the IEEE website and download this document to review.  No one on the call 
  said that this would be a problem.
	-this AR will be closed.

- Macro Library Documentation
  - Mike will get to this in Nov

-------------

Opens:

-  Arpad will be travelling on vacation next week, may not be able to attend.  Michael Mirmak has tentatively volunteered to host the
   meeting.  If he cannot for some reason, Mike Labonte could host; Walter Katz will be Mike's backup.

-------------
New Discussion:

-  Kumar began the meeting discussion by presenting "AMI Proposal Background-Proposed Changes to IBIS API Specifics"
	-  2 main things done by AMI models:  TX & RX equalization, and clock recovery.
	-  There are all kinds of postprocessing that could be done by the EDA tool...these things are NOT covered by the API proposal.
	-  Main goal of API proposal is to be simple and flexible.
	-  An example case, with a 4-tap TX, modeled with traditional IBIS capability (VI curves, Spice, AMS, whatever...could be modeled
	   from information in the datasheet, typically), and an RX which is represented with a simple load model, was covered in the prez.
	   In this case the TX had user-defined tap-selections (no optimization).
	-  Kumar showed the waveform corresponding to the impulse response resulting from the IBIS simulation, which would be fed to the AMI models
	   for subsequent processing.
	-  Arpad/Michael M.:  Do we really only need 1-bit of characterization for the impulse response?
	-  Kumar:  Yes, subsequent processing, such as FIR filter application, will capture all of the taps for the TX, for example (in an ideal sense).

- Proposed changes to IBIS
	-  Cadence proposes a new section called something like "AMI"
	-  Parameters can be contained here.  This section needs to be flexible in that parameters will be very device-specific.
	-  It was noted that if the model doesn't get required information that is needed for it's initalization or operation, there must be
	   some error mechanism specified.
	-  In this proposed scenario, every model must come with some documentation explaining what the parameters are for, what they do.
	-  The number of parameters and their type are not restricted.
	-  We then digressed into more software centric discussions...

-  More detail about Functions/Calls
	-  AMI_Init, AMI_Getwave, AMI_Close, should be in EVERY AMI model.
	-  Barry:  Trying to understand the structure here...these functions are in an executable somewhere?
	-  Kumar:  Point is that the function calls are always the same (that is, the function ARGUMENTS are the same).  Some arguments may contain a lot
	   of parameters in a character string.
	-  What does the AMI_Init do in the case of receiver initialization?
		-  Kumar:  The impulse reponse is passed as a matrix, and the RX AMI model may modify it "in place" (reference the pdll_server_param_obj
		   argument).  In other words, it is done in "private" data space for the model, and will only be acted upon later by the AMI model 
		   itself.  AMI_Getwave can use this data.  No other function needs to know about it anyway.
	-  Based on ONE AMI_Init, AMI_Getwave may be called 100s or 1000s of times.
	-  Kumar proposed to put clock edge times in a "clock tics" vector, something like [0 200e-12 400e-12 ...]
	-  Waveforms may need to be resampled in order to provide uniform timesteps, etc.
	-  EDA tool must know what the function arguments are and what they mean.
	-  Arpad:  Need to keep defining what is needed in IBIS to enable all of this to happen.
	-  Ian:  We should discuss the potential drawbacks of this approach, such as the consequences of adaptive time-stepping.

AR:  Lance will send the presentation to Mike Labonte.  Mike will post to the website.  We should all make an effort to comment on this.  Don't hesitate
     to use the reflector for this.

-------------

Next meeting: Tuesday 14 Nov 2006 12:00pm PT